【レポート】Architecting for the Cloud 2019 – クラウドにおけるアーキテクチャの設計原則 #AWSSummit

AWS Summit 2019 Tokyo からセッションをレポートします。このレポートは、「Architecting for the Cloud 2019 - クラウドにおけるアーキテクチャの設計原則」です。

AWS Summit Tokyo 2019

#イベントレポート

#レポート

#AWS

まさを

2019.06.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさま Xin chao.

2019/6/12(水)～14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。

このレポートは、「Architecting for the Cloud 2019 -クラウドにおけるアーキテクチャの設計原則」です。

概要

AWSを使ってセキュアで、信頼性が高く、高性能で、コスト効率の高いシステムを設計するには、どうしたらよいでしょうか？

本セッションでは、AWS のメリットを活かした、クラウドらしいアーキテクチャを構築するための原則をご紹介します。伸縮自在性に代表されるクラウドコンピューティングならではの動的な性質を活かすための考え方を学び、AWS らしい設計を行うために意識すべきベストプラクティスについてご紹介します。

クラウドにおけるアーキテクチャの設計原則をあらためて見直す (そして議論できるようにする)
Webアプリにおける実践を通じて、この原則を理解する

スピーカー

アマゾンウェブサービスジャパン株式会社技術統括本部ソリューションアーキテクト荒木靖宏様

レポート

基本中の基本

Amazon EC2

設定済みの VM
VM 動作中 / 停止中 - 動作させた VM はいつでも停止させることができる
EBS Snapshots (S3) - いつでも S3 にスナップショットを作成可能, スナップショットで AZ 間を移動

Amazon VPC

論理的に分離された環境でネットワークを構築
VPC Endpoints - AWS サービスへのプライベートでセキュアな接続
Shared VPC では VPC環境を複数のアカウントで共用可能 - ネットワーク管理者とアプリ開発者が別の場合などに活用

AWS Global Infrastructure

21 geographic regions
61 Availability Zones
99.99% の可用性SLA

Architecting for the Cloud 2019

障害を見越した設計

冗長化
障害の検出 (止まっても〇〇時間で復旧します)
永続データストレージ (自分のデータが失われていないか)
複数データセンタを用いた自動復旧 (AZをうまく使う)

全レイヤでのセキュリティ実装

徹底的な防御 (できるところを徹底的に)
AWS のセキュリティサービスを積極的に使用 (使えるものは使う)
特権アクセス制限 (ルートアカウントではなく必要な権限を使う)
リアルタイム監査 (可能な限りリアルタイムを目指す)

ストレージの選択肢活用

S3
EBS
Glacier
Elastic File System
Aurora
DynamoDB
ElastiCache

伸縮性の実現

ブートストラッピング or Golden Image
ユーザーデータでブートストラッピングできればいつでも最新の AMI を利用可能
Golden Image を作る場合は伸縮できるように作成する
家畜として扱う (1つ1つに手間をかけて育てるペットではなく家畜として育てる)
替えが効くサービス
サービス継続性の重視
1つ 1つの EC2 が落ちてもサービスに影響がないように

並列で考える

1台で100時間＝ 100台で1時間で終わるのでは？という考え方
なめらかなスケーリング
障害影響範囲を小さく
ソフトウェアの書き換え (ソフトウェアの制限を解消する)

疎結合はあなたを楽にします

よいインターフェース定義
サービス拡張
対応できない時の非同期処理 (SQS を使うだけでも疎結合が楽になる)
失敗時の適切な処理 (失敗したら SQS にもう一度入れなおす, DynamoDB に今の状態を書いておくでも OK)

制約を恐れない

制限には理由がある (EC2 の起動制限など)
提供できるものを計画する (100% を目指すといつになるか分からない)
うまくいくものを出荷する
できるときに出荷する
繰り返し繰り返す

実践 (Web アプリ編)

セキュリティは常に最優先

必須：アカウント要不要と権限管理、証跡

Production アカウントについては少なくとも次の 3 つを実施

IAM ユーザー／グループの設定 (アカウントを共用しない)
CloudTrail, Config, GuardDuty, Security Hub, MFA の有効化 (非常に安価)
Enabling and Disabling Regions (使わないリージョンは使わなくする, 香港リージョンから使用時は Enable にする必要がある)

AWS Controll Tower というランディングページを準備中。
https://aws.amazon.com/solutions/aws-landing-zone/

AWS 上の基本的な構成

(Public Subnet) ALB ＋ (Private) Subnet EC2 / S3 Backet

セッション情報は外に出す

スケールさせやすくするためにセッション情報は外だし (まだまだできていない環境が多い)
書き換えられても問題ない情報、肥大化の恐れがない情報は Client-Side

AWS のサービスを活用した非同期処理の例

SQS を挟んで Frontend と Backend を疎結合に

計算資源を使い捨てるために

ブートストラッピング
- Cloud-init を使用したソフトウェアインストール、各種設定
ゴールデンイメージ
- 特定の状態でスナップショットを取得
コンテナ
- ECS の Docker サポート
- 必ずしもコンテナ化がゴールではなく SQS, セッション外だしだけで済む場合もある

AWS 上の基本的な構成と防御

オリジンへの外部からのアクセス禁止

S3 Origin Access Identity
S3 バケットへの直接アクセス防止
直接アクセス可能な S3 URL 廃止
Custom Origin Security Groups
CloudFront の IP レンジのホワイトリスト

今日の Web アプリに対する最大の脅威

DDoS
App Vulnerabilities
Bad Bots

CloudFront による防御レイヤ追加

CloudFront を入れておけば WAF の導入が容易
複数アカウントを束ねるために Firewall Manager を提供

DDoS 対策用の防御レイヤ追加

AWS を使うだけで L4 レベルの攻撃を防御可能
それ以上の防御は Shield Advanced

まとめ

障害を見越した設計
全レイヤでのセキュリティ実装
ストレージ選択肢活用
伸縮性の実現
並列で考える
疎結合はあなたを楽にします
制約を恐れない

AWS Well-Architected Tool を見ることを設計原則に取り入れる

セルフサービスで Well-Architected Framework を活用できる
活用が難しいお客様には Trusted Advisor (ビジネスサポート契約で全機能を利用可能)

参考資料 (ホワイトペーパー)

Architecturing for The Cloud : AWS Best Practices
AWS Well-Architected フレームワーク

Well-Architected Tools を合言葉に！

感想

あらためて全体を通して聞くことで、普段何気なく構成しているのには理由があり、メリットもあることが分かりました。

また、AWS で古くから提供されていた SQS がプッシュされていたのが印象的でした。

【レポート】Architecting for the Cloud 2019 – クラウドにおけるアーキテクチャの設計原則 #AWSSummit

概要

スピーカー